-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ArrayVec::as_inner() #197
Conversation
Originally I was going to call this `as_array()` but `as_inner()` is more consistent with the existing `into_inner()` method. I don't _ultimately_ care what it ends up being called. I wonder if we should have a `impl From<ArrayVec<T>> for A` implementation or is that a bit too foot-gun-y? This lives in its own `impl<A> ArrayVec<A>` block because rust 1.47.0 is unhappy about having a const function inside `impl<A: Array> ArrayVec<A>`. We don't need the trait anyway. Fixes Lokathor#193.
I updated the commit to make it compile on 1.47. |
I think |
Released in |
I meant having a I think it's fine not to have it for now. |
Is it "safe" to access elements that are past the end of the vec because those elements are always the Default value rather than some undefined behavior, thanks to initializing with the default or (I'm not trying to suggest there is a bug, just curious if I'm understanding why this is ok correctly) |
Yes, the spare slots are not "in the list", but they're always initialized data, so it's safe to access them. |
I didn't think we could rely on the elements past the "end" being the Default but maybe we can? If yes, can this get documented and made official? This is useful knowledge. I assumed some operations just leave the data as-is without dropping it. I thought |
I'd have to check closely, but I believe that they will not always be the |
Originally I was going to call this
as_array()
but
as_inner()
is more consistent with theexisting
into_inner()
method. I don'tultimately care what it ends up being called.
I wonder if we should have a
impl From<ArrayVec<T>> for A
implementation or is that a bit too foot-gun-y?Fixes #193.